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REMARKS 



Upon entry of this amendment, claims 19-37 will be pending. Claims 1-6, 8-14, and 
16-18 have been canceled. No claims have been amended. Claims 19-37 have been added. 
Claims 19, 32, and 35 are the independent claims. 

No new matter has been added. Support for the claims may be found in the 
specification as originally filed, inter alia, at pages 8 through 13. Specifically, pages 8 and 9 
describe the request and response processing, page 10 describes cache processing, page 11 
describes an exemplary fail-over, page 12 describes server "keep alive" processing, and page 
13 describes that the network access processing is transparent to the user and the client 
application. 

Claims 1-6, 8-14, and 16 were rejected under 35 U.S.C. § 102(e) as allegedly being 
anticipated by United States Patent No. 6,801,949 to Bruck et al. ("Brack"). Claims 17 and 
18 were rejected under 35 U.S.C. § 103(a) as allegedly being obvious over the teachings of 
Brack in view of United States Patent No. 5,774,660 to Brendel et al. ("Brendel"). Claims 1- 
6, 8-14, and 16-18 have been canceled, thereby obviating the rejections. 

New claims 19-37 have been added to more distinctly and clearly describe the 
claimed subject matter. The new claims distinguish over the cited references, because the 
Brack and Brendel do not disclose a computer fail-over scheme where the data connections 
are over the Virtual Interface Architecture (VIA) protocol and where the fail-over processing 
occurs transparently at a network access module. 

The present application discloses a client computer that may include a client 
application and a network access module. The client application may communicate with a 
cluster of servers. For simplicity, the cluster of servers may include a first server and a 
second server. The client computer may engage a VIA connection with the first server. The 
VIA connection may include VIA formatted packets. This first server may map to a server 
name. When this connection fails, the client computer may fail-over the connection to the 
second server. The second server may also map to the same server name. Since VIA 
supports machine-level identification, not abstract server names, additional processing is 
required to resolve the single server name to the first physical server, while the first physical 
server is available, and then to the second server, when the first server fails. 
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The network access module, of the claimed invention, may provide this fail-over 
processing transparent to the client application {Specification - p. 13, 11. 13-27). The network 
access module may detect that a connection has failed. The network access module may send 
a request to the cluster of servers. The second server may respond to the request, and the 
network access module may establish a connection with the second server. The client 
application may be unaffected by the fail-over, since the processing occurs at the network 
access module. Furthermore, since the network access module is part of the client computer, 
the solution does not require additional, intermediate, network elements to handle the fail- 
over. This context and approach is different from that presented in the cited references. 

The cited references, Bruck and Brendel, do not disclose the claimed fail-over 
method, computer readable medium, and system. For example, Bruck and Brendel do not 
teach a client-based (i.e., network access module) fail-over approach for VIA protocol 
communications. Rather, they disclose a conventional, network-based load balancing 
approach for TCP/IP protocol communications. 

The Bruck and Brendel systems are network-based, not client-based. For example 
FIG. 21 of Bruck shows a network-based router and four servers that load balance traffic for 
a web server. FIG. 8 of Brendel shows a network-based load balancer that operates between 
the client and the server. 

The Bruck and Brendel systems are designed for the TCP/IP protocol, not the VIA 
protocol. For example, FIG. 4 of Bruck shows TCP and IP layers within the network stack. 
Also, FIGS. 7, 12, 13, 14, and 17 of Brendel show the role of TCP/IP within the disclosed 
asymmetrical load balancer. Although Bruck states that "other network protocols may be 
accommodated," Bruck does not disclose any processing or connections with the VIA 
protocol. 

Furthermore, because the fail-over processing, in Bruck, happens within the network, 
rather than at the client computer, connection failures are not transparent to the client 
application. In Bruck, a server failure results in a fail-over at the load balancer by re- 
assigning virtual IP address (Bruck, c. 6, 1. 45 - c. 7, 1. 2) . Because Bruck' s load balancer is 
in the network, the load balancer cannot process or even detect connection failures that may 
occur at any point between the client and the server. Rather, the load balancer in Bruck, by 
nature of its location, can only process a fail-over at the servers themselves, and not for the 
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overall connection between the client and the server. A connection failure, in Bruck, would 
not be transparent to the client application. Rather, the client application would have to re- 
establish a new connection to the load balancer and ultimately to the servers. This is different 
than the fail-over processing operated by the network access module, of the claimed 
invention. Because the network access module operates at the client computer, the entire 
connection between the client computer and the server may be monitored for a failure. Thus, 
the fail-over processing for a connection failure is made transparent to the client application. 

The Examiner cites the "virtual IP interface" described in Bruck as disclosing VIA, 
generally. However, a "virtual IP interface" on its face is an IP, Internet Protocol, interface, 
and cannot disclose VIA generally. As understood by those skilled in the art, VIA protocol is 
different protocol from Internet Protocol, in that VIA bypasses device operating systems. 
VIA is typically used in high speed applications such as server clusters. As a result, VIA 
communications generally have lower latency than their TCP/IP counterparts. Furthermore, 
the VIA protocol relies on VIA formatted packets, not IP formatted packets. 

Accordingly, Applicant submits that the present application is in condition for 
allowance. Reconsideration of the application and an early Notice of Allowance are 
respectfully requested. 
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